As the value and use of information continues to increase, individuals and businesses continually seek additional ways to process and store information. One option available to users of information is an information handling system. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes, thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary with regard to the kind of information that is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use, including such uses as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Examples of information handling systems, such as computers, including servers and workstations, are often grouped in clusters to perform specific tasks. A server cluster is a group of independent servers that is managed as a single system and is characterized by higher availability, manageability, and scalability, as compared with groupings of unmanaged servers. A server cluster typically involves the configuration of a group of independent servers such that the servers appear in the network as a single machine or unit. Server clusters are often managed as a single system, share a common namespace on the network, and are designed specifically to tolerate component failures and to support the addition or subtraction of components in the cluster in a transparent manner. At a minimum, a server cluster includes two or more servers that are connected to one another by a network. The server cluster may include software driven methods by which each client of the server cluster may access the data stored in or controlled by a server of the server cluster. One software application that is used to manage the operation of a server cluster is Microsoft Cluster Service (MSCS), which is produced by the Microsoft Corporation of Redmond, Wash.
In some server cluster configurations, many components of the server cluster are redundant, allowing the component to be replaced or upgraded while the server cluster is online in the network and without affecting the operations and/or services provided by the server cluster to the clients on the network. Server clusters often include a shared storage element in which each drive of shared storage is accessible by each node, or server, of the server cluster. From time to time, the firmware associated with the storage drives comprising the shared storage must be updated. The process of updating the firmware of a storage drive may involve taking the storage drive down or offline and updating the firmware. This step may be followed by a reboot of the storage drive in which the storage drive is placed back in service in the shared storage of the server cluster.
The shared storage of the server cluster may include fault tolerant data storage. One example of fault tolerant data storage is a redundant array of independent disks (RAID) storage system. RAID storage systems combine multiple disks into an array of disk drives to obtain performance, capacity, and reliability advantages. RAID Level 5 is an example of a fault tolerant data storage system. A RAID Level 5 storage system is characterized by the striping of data across the disks of the storage system. A set of parity bits generated by an exclusive-OR of the striped data bits is stored on a disk that is separate from the striped data. The parity bits for the respective stripes of data are distributed in the disks of the storage system so that each disk will likely contain both data bits for a stripe of data and parity bits related to some other stripe of data. In a RAID Level 5 storage system, it is typical that no single disk includes all of the parity bits or all of the data bits. RAID Level 5 is often referred to as a rotating parity storage system. If a disk of a RAID Level 5 storage system fails, the data (including the data bits and/or the parity bits) can be rebuilt by performing an exclusive-OR operation with the data of the other disks in the stripe, including the parity bits associated with the data stripe. Other RAID levels may be implemented for fault tolerance, including RAID 10, RAID 1, RAID 3, RAID 6, and the like, for example.
Storage systems based on peripheral component interconnect (PCI) RAID controllers, for example, PERC with PV220xS available from Dell, Inc., are common. Generically, these RAID controllers are server host based and connected to a JBOD (just a bunch of disks) enclosure. In such storage architectures, there are several operations that should be performed by the RAID controller when the storage device is not very busy. Examples of such operations include background initialization, read patrol, rebuild, and/or read cache. Within the RAID controller firmware, these nonessential input/output (I/O) operations (NEIs) are usually scheduled with lower priority than regular input/output (I/O) operations. However, in the cluster environment, where two or more server nodes with their RAID controllers are attached to the same storage, sometimes these nonessential input/output (I/O) operations (NEIs) from one server node can affect more useful input/output (I/O) operations being performed on other nodes sharing the same bus.
Consider a conventional 2-node cluster 1100 based on SCSI, Fibre Channel, SAS, or any applicable technology, with the conventional 2-node cluster 1100 as shown in FIG. 11, for example, with cluster node (or server) A 1110 and cluster node (or server) B 1120. The cluster node B 1120 can be very busy accessing a logical unit number (LUN) of a storage system subunit 1130, such as a production LUN 1140, as indicated by arrows 1125, while the cluster node A 1110 may be very idle. The controller firmware on the cluster node A 1110 can kick off low priority nonessential input/output (I/O) operations (NEIs) with 100% utilization, such as by accessing an LUN requiring maintenance 1150 of the storage system subunit 1130, as indicated by arrows 1115, for example. However, these low priority NEIs 1115 with 100% utilization can seriously affect the regular input/output (I/O) operations 1125 from the cluster node B 1120. For example, business applications on the cluster node B 1120 would incur long input/output (I/O) response times and the connected clients, in turn, would see unnecessarily slow server response. In such a scenario, the conventional 2-node cluster 1100 performance may be degraded.
With clustering storage solutions becoming more popular, there is a need for the controller to be able to determine the amount of NEIs that should be sent to the shared storage system in the cluster environment without adversely affecting the overall performance of the cluster. In a standalone environment, the RAID controller, for example, can currently examine its own queue to determine if it is busy or not. However, there is no mechanism for the RAID controller to determine the storage utilization for an entire cluster configuration including more than one server sharing the same storage system.